零知識證明結構分為交互式和非交互式兩大類別:
1 交互式零知識證明(Interactive Zero Knowledge Proof (iZKP))
交互式零知識證明需要證明者和驗證者之間進行至少一次交互，以確保零知識證明正確進行。
在交互式零知識證明中，證明者和驗證者會進行一次或多次交互，過程中需要交換訊息來證明證明者擁有相關知識。
當中最常用的是Fiat-Shamir heuristic，驗證者會產生一個隨機值然後用於對證明者的挑戰。
證明者在接收到驗證者的挑戰後，必須使用他所擁有或知道的秘密知識來產生一個對挑戰的回應(需要進行一項計算，然後返回結果)，
然後驗證者在收到證明者的回應之後，可以驗證那個回應是否正確。
如果回應正確，驗證者會接受證明(確認回應是真的)及確認這次交互完成。
交互式零知識證明的其一個主要優勢是它們的高度靈活，可用於證明許多不同類型的資訊知識。
例如，它可用於證明某人知道秘密值(例如:大門密碼/軟件密碼)，
或證明他們對數字資產(例如: 加密貨幣/知識產權/數據)具有一定程度的權限或擁有權。
交互式零知識證明的另一個優點是它十分安全。
因為隨機挑戰中的使用及證明者和驗證者之間交互的方式可以使到造假風險大大降低。
不過交互式零知識證明也有存在一些缺點。
主要缺點是它需要證明者和驗證者之間高度信任。
如果任何一方受到損害或入侵，證明的安全性就會受到影響。
另外，執行交互式零知識證明的過程可以會非常花費時間，因為需要證明者和驗證者之間進行交互，
而且更需要大量的運算資源(算力)，從而對應用普及上造成一些局限。
這個交互過程需要重復多次進行，目的是確保證明者在不知道秘密信息的情況下而又猜出正確答案的概率變得足夠低。
2 非交互式零知識證明(Non-Interactive Zero Knowledge Proof (niZKP))
非交互式零知識證明是不需要證明者和驗證者之間互動的ZKP。
相反，證明者創建一個可以由驗證者驗證而無需任何交互的證明就可以，之後就給驗證者去做驗證。
最常見的非交互式零知識證明之一是 SNARK (Succinct Non-Interactive Argument of Knowledge)。
SNARK使用高階的數學演算法來創建可由驗證者無需任何交互即可驗證的證明。
證明通常是產生要證明是資訊簡短的、高度壓縮的，驗證者會驗證該證明是否有效。
非交互式零知識證明的主要優點是它們比交互式零知識證明更有效率且可擴展。
由於證明者和驗證者之間沒有交互，因此可以更快地驗證，而且可以使用更少的計算資源。
不過，非交互式零知識證明也存在缺點，其中一個主要缺點是它們不如交互式零知識證明靈活，
並且只能用於證明某些類型資訊的知識。
交互式和非交互式的確各有其優缺點。交互式零知識證明高度靈活且安全，但可能非常耗時，並且需要相關各方之間高度信任。
非交互式的更有效率及可擴展，但靈活性可能較差。
在當下生態中﹐比較多人關注/使用的零知識證明系統有以下3類，
分別有 ZK-SNARK、ZK-STARK、Recursive SNARK(遞歸SNARK)。
ZK-SNARK (全稱 Zero-Knowledge Succinct Non-Interactive Argument of Knowledge)，是一種用於產生零知識證明的協議，
在不暴露底層資料的情況下驗證資訊的真實性。
ZK-SNARK 協議主要有兩個角色：證明者和驗證者。
證明者（Alice）是提出主張的一方，而驗證者（Bob）則是負責驗證主張的一方。
而主張會被稱為witness(證人)或者secret(秘密)。
證明者（Alice）使用 ZK-SNARK 機制產生證明，然後會向驗證者（Bob）表示該聲明是真的，但又不用透露引用的資訊。
以下會以一個例子說明:
ZK-SNARK具有以下特質:
ZK-SNARK有什麼優點?
高吞吐量、小有效性證明大小和安全性。
數據小的證明
SNARK證明的數據小就可以易於在主鏈上進行驗證。
例子:
在以太坊上，驗證鏈下交易的gas fee較低，用戶的總和成本也因此降低。
安全性
ZK-SNARK 中使用了尖端的加密安全機制。
另外，ZK-SNARK 證明具"計算可靠"的特性，所以可以進一步讓惡意行為更難實現。
ZK-SNARK 的非互動性也意味著任何人都可以不可信地驗證證明。
ZK-SNARK 的有什麼缺點？
使用 ZK-SNARK 有三個主要缺點：它需要可信任設定、容易受到量子運算攻擊以及依賴特殊硬體。
可信任的環境設置
設定 ZK-SNARK 協議時，需要建立通用公共參考字串 (Common Reference String: CRS)。
CRS 也被稱為公共參數，可實現證明者和驗證者之間的安全溝通。
如果惡意行為者獲得到公共參數，他們有機會產生虛假的有效性證明。
有些項目試圖利用多方計算(MPC)來產生公共參數以解決這個問題。
不過這種方法要求使用者必須信任相關人員的誠信。這就會形成一個矛盾的問題，因為區塊鏈的出現是想做到去中心化，減低信任的依賴。
容易受到量子計算攻擊
ZK-SNARK利用橢圓曲線密碼技術(ECC)來加密會用於產生有效性證明的資訊。
ECC目前是安全可靠的，不過隨量子計算的發展，將會有可能破壞到ECC的安全機制。
對指定硬體的依賴
利用ZK-SNARK產生有效性證明是一個密集型的計算過程，因此證明者必須使用到有足夠算力的硬體以支持計算過程。
當然要使用到怎樣的硬件是取決於項目對ZK-SNARK產生有效性證明的要求是怎樣及其他相關要求標準。
ZK-STARK (Zero-Knowledge Scalable Transparent Argument of Knowledge)。
是一種零知識證明系統，由 Eli Ben-Sasson、Iddo Bentov、Yinon Horesh 和 Michael Riabzev
在 2018 年的論文中作為 SNARK 的替代方案引入。
如論文中所述，STARK 可以為當下的社會帶來好處：
「"人類的尊嚴(Human dignity)"要求向公眾隱藏用戶的個人訊息，例如醫療和法醫方面的數據。
但在保護隱私的事件上也可能被負責處理資料的機構濫用來掩蓋謊言和欺騙，不公正地傷害大眾及削弱對政府機構的信任。
零知識證明技術是一種巧妙的密碼學解決方案，可以解決個人隱私與機構誠信之間的緊張關係，
以不損害前者的形式強制地讓後者實施相關方案。」
像 ZK-SNARK 一樣，可以展示一個有效的陳述而不透露陳述本身的任何內容。
STARK 與 SNARK 是具有相同的屬性。所以STARK-based的有效性證明是能夠使用一條對驗證者隱藏的資訊產生，
同樣可以在不洩漏輸入的情況之下，驗證交易的正確性。
ZK-STARK有什麼優點?
具透明的(transparency):
因為它可以在沒有公共參考字符串(Common Reference String: CRS)的可信設置的情況下執行。
是可擴展的(scalability):
STARK具有更大的證明大小，會更適合在更大型的計算。使用ZK-SNARK的話，證明和驗證的複雜性規模與底層計算會是線性關係。
不用可信任的環境設定
ZK-STARK 不需要可信任的環境設定就可以立馬運行，而是依賴公共的隨機性。
因此這樣減少了用戶的信任假設，及提高了基於STARK的協議的安全性。
更高的安全保護
ZK-STARK 使用抗碰撞雜湊進行加密，而不是 ZK-SNARK 中使用的橢圓曲線方案。
這被認為可以抵抗量子計算的攻擊，因此比 SNARK 中使用的橢圓曲線更安全。
在驗證一個需要計算量更大的情況下，ZK-SNARK協議需要比ZK-STARK需要更多的時間來生成證明和驗證證明。
因此STARK會更適合處理大量交易的應用場景。
ZK-STARK 的缺點是什麼？
使用ZK-STARK的兩個主要缺點是它使用更大的證明大小，及在區塊鏈空間中採用情況較少。
更大的證明大小
雖然STARK提供了更快速的證明計算，不過其缺點是這些證明與基於SNARK的證明大小相比會更大。
這讓STARK證明在以太坊(區塊鏈上的數據大小會影響到成本)上的驗證成本更高，
因為計算更大的證明是需要更高的gas fee。
採用率較低
SNARK是零知識技術在區塊鏈中的第一個實際應用，這就是為什麼它們比STARK擁有更多的市場佔有率。
在現在的生態，大多數ZK rollups都使用ZK-SNARK。
儘管ZK-STARK也有一些知名/大型組織的支持者，包括以太坊基金會，但他們的採用率較低。
因此，行業中的開發人員會發現使用STARK開發零知識證明項目的支持和工具也相關較少。
從而可想而知，要是想開發STARK項目，就會投放更多時間和資源。
遞歸SNARK(Recursive SNARK)可以為每一層計算或遞歸產生一個證明，然後將這些證明遞歸地組合成一個以產生整個計算的證明。這表示一個SNARK可以驗證其他SNARK。
這更可以有效地去驗證涉及大量遞歸的計算，例如涉及 Merkle 樹、graph computations和區塊鏈的計算。
遞歸ZK-SNARK是如何運作?
證明的遞歸組合會有以下三個步驟:
遞歸ZK-SNARK有什麼優點？
總結，可以留意到ZK-SNARK、ZK-STARK、Recursive SNARK(遞歸SNARK)各有分別，然而在每個類型之下也有不同產品，可以因應不同的需求及場景選用合適的方案。
參考:
iThome鐵人賽
看影片追技術